macOS is the primary shipped platform but e2e only ran on Linux, so a
whole class of platform/path bugs went uncaught in CI. The afterPack
Linux-vs-macOS executable-name divergence is the canonical example:
mac uses productFilename, Linux uses executableName, and only running
the suite on both surfaces that kind of drift.

Add a fail-fast:false os matrix (ubuntu-latest, macos-latest). The
Linux-only steps stay gated so the ubuntu leg is byte-for-byte the same
work as before: the Electron-binary unzip workaround (linux-x64 zip,
dist/electron) and npx playwright install-deps are guarded with
if: matrix.os == 'ubuntu-latest', and xvfb-run wraps the suite only when
RUNNER_OS is Linux. macOS extracts dist/Electron.app via the normal
postinstall and has a real display, so it needs neither. The venv
provisioning and JLAB_TEST_PYTHON_PATH work unchanged on both. Artifacts
are named per-OS so the two legs do not clobber each other.

Note: AI-assisted (Claude Code). Manually verified: yaml parse (python yaml.safe_load) + that the ubuntu leg is unchanged (same steps, same commands, gates only add macOS); macOS leg verified by reading, not run (cannot run macOS CI locally).

The macOS Playwright leg failed with "Electron failed to install
correctly": extract-zip leaves dist without the app binary on the runner,
the same way it does on Linux, but only the Linux leg had a repair step.
Mirror that fallback for macOS using ditto, which preserves the Electron
Framework symlinks that plain unzip would mangle. The step is conditional
and logs whether it fired so the CI log shows the real on-disk state.

Note: AI-assisted (Claude Code). Manually verified: reproduced ditto -x -k
extraction of the cached darwin-arm64 zip locally (binary lands executable
at Electron.app/Contents/MacOS/Electron as Mach-O arm64, Framework
Current->A symlink preserved); confirmed local electron 27.0.2 install
state matches isInstalled() expectations.

The repair step reports the binary present yet electron.launch still throws
"failed to install correctly". Dump path.txt, the resolved module path and
require('electron') output on the runner to find the real cause before
fixing. Diagnostic scaffolding, removed once the cause is known.

Note: AI-assisted (Claude Code). Manually verified: step is macOS-only and
non-fatal; reads on-disk state only.

…e abort)

Note: AI-assisted (Claude Code). Manually verified: diagnostic-only, reads state.

The macOS Playwright leg failed with "Electron failed to install
correctly". CI diagnostics showed the real cause: dist/Electron.app and
dist/version are present and the binary is executable, but extract-zip never
wrote node_modules/electron/path.txt, and electron/index.js resolves the
executable from path.txt, not the binary. Always (re)write path.txt in the
repair step (its macOS value is constant), keeping the ditto re-extract only
for the case where the binary itself is missing. Verify resolution in-step
with require('electron').

Note: AI-assisted (Claude Code). Manually verified: diagnosed from CI logs
(path.txt missing, binary present, require('electron') stack at index.js:17);
ditto extraction of the cached darwin-arm64 zip reproduced locally.

The path.txt fix surfaced the real defect: extract-zip leaves the launcher in
place but an incomplete Electron Framework.framework, so dyld fails with
"Library not loaded: @rpath/Electron Framework.framework/Electron Framework"
at launch. The previous repair skipped the re-extract when the launcher was
present, so it never replaced the broken framework. Re-extract the cached
darwin zip with ditto unconditionally (it reproduces a complete .app with the
144MB framework binary and the Versions/Current symlinks intact, verified
locally) and assert both the launcher and the framework binary exist.

Note: AI-assisted (Claude Code). Manually verified: ditto extraction of the
cached darwin-arm64 zip locally yields the framework binary at Versions/A and
the top-level Electron Framework symlink; diagnosed the dyld failure from the
CI launch log.

The cache-root glob found nothing: @electron/get stores the zip under a
content-hash subdirectory (~/Library/Caches/electron/<hash>/electron-...zip),
not at the cache root, so 'ls .../electron-*-darwin-*.zip' failed. Ask
@electron/get for the path directly (it returns the cached zip, downloading
only if absent), then ditto-extract as before.

Note: AI-assisted (Claude Code). Manually verified: ran the same
downloadArtifact one-liner locally, it returned the hashed cache path.

Audit-driven robustness pass on the e2e suite:
- Add pageByUrl and pageByLocator helpers. pageByUrl polls every open page's
  URL, so it catches an in-place navigation of an existing view (how the remote
  session loads) as well as a new window, unlike waitForWindowByUrl which only
  fires on a new-window event. Replace all waitForWindowByUrl uses with it.
- Start the remote test server with python -m jupyterlab instead of the
  jupyter-lab launcher path so it resolves the same on Windows, macOS and Linux,
  isolate it to its own temp HOME / JUPYTER_* dirs, and capture spawn errors
  into the readiness loop instead of throwing from an event handler.
- Find the connect dialog by a stable element (#server-url) and click a new
  #connect-remote-link id rather than matching the English link title.
- Tighten the post-wait assertions from /:port/ to /lab so a navigation to a
  non-lab URL is caught.
- Add the Windows runtime-dir branch to the isolation test.

Note: AI-assisted (Claude Code). Manually verified: built and ran the full e2e
suite locally against jupyterlab 4.5.6 with --workers=1 (the CI setting), 10
passed; confirmed python -m jupyterlab and the env has jupyterlab 4.5.6 plus
notebook 7.5.5; verified the embedded server and the test server both pass
--no-browser and that a full run opens no external browser (process count
unchanged before/after). Patterns cross-referenced against JupyterLab Galata.

Move the booted-server URL regex (was duplicated inline in three tests and a
local const in a fourth) and the 'set JLAB_TEST_PYTHON_PATH' skip reason into
helpers as LAB_URL and NEEDS_PYTHON, and use them everywhere so every
server-backed test waits on and skips for the same thing. No behavior change.

Note: AI-assisted (Claude Code). Manually verified: full e2e suite green
locally with --workers=1 (10 passed), eslint and prettier clean.

CI hit 'Target page has been closed' on the dialog.evaluate: the connect
ThemedWindow loads asynchronously, so the page handle pageByLocator returns can
go stale as the window navigates. Wrap the find-and-submit in expect().toPass()
so it re-finds the dialog and resubmits until it sticks; evaluate runs once on
success, so the setRemoteServerOptions IPC is sent at most once.

Note: AI-assisted (Claude Code). Manually verified: ran remote-session 5x
locally with clean state between runs, all passed; the earlier CI run flaked
once on this exact evaluate call and recovered on retry, which this removes.

The second CI flake mode was 'no window contained selector #server-url': the
connect dialog never opened because the click on the always-enabled remote link
landed before the welcome page's scripts and electronAPI were ready, so the
onclick was a no-op. Wait for #new-notebook-link to lose its disabled class
first (the app's existing readiness signal, already used by the other
server-backed tests) before clicking, so the click always reaches a wired page.

Note: AI-assisted (Claude Code). Manually verified: ran remote-session 4x
locally with clean process state between runs, all passed; the readiness wait
matches the convention python-env and session-actions already use reliably.